This looks good, but I would like to see this actually running on WASM before merging. In particular, the reason for making this method async is that (AFAIK) polling the surface aquisition future with pollster won't work on WASM (because the future is comes from the JS runtime which can't make progress while our wasm code is blocking), and that we need to spawn it with wasm_bindgen_futures, and then actually await and then handle the result in async manner.

So this does make the resume method async, but I don't think it's going to work with the WindowRenderer actually running with a Winit application/window. This is because the async method holds a mutable reference to self, and I think that's going to run into borrow-checking issues.

I think perhaps a channel might by the best way around this. When the async surface creation completes it could send it back to the WindowRenderer through a channel, resolve the future, and then the setup could be completed on the next call to render.

We might also consider having resume take a callback to call once the surface is ready (instead of making it an async function). Then we could keep all the future/async machinery inside the WindowRenderer (the caller would then generate a Winit event (e.g. request_redraw or a custom event) when the callback is called).